This is a comment left during a code review.
Path: ui/src/components/MultiModelResponse/MultiModelResponse.tsx
Line: 701-724

Comment:
**Artifacts double-counted in `allOutputArtifacts`**

`streamWithClientSideTools` always returns **both** `completedRounds` (with `toolExecution` on each round) and `toolExecutionRounds` (the same rounds, separately). Both are stored in the conversation and passed down as `response.completedRounds` and `response.toolExecutionRounds`, which means `toolExecutionRounds` is never empty when `completedRounds` is set.

The current memo loops over both paths and pushes the same output artifacts twice — once from `completedRounds[i].toolExecution.executions` and once from `toolExecutionRounds`. The comment "Also check standalone toolExecutionRounds (single-round path)" reflects the intended guard, but the guard is missing: `toolExecutionRounds` is non-empty for multi-round responses too.

The `find` call in `ContentRound.displayedArtifacts` returns the first match per ID, so rendering itself won't duplicate artifacts, but `allOutputArtifacts` is larger than necessary and any code path that iterates or counts it (e.g. deduplication logic added later) will see phantom duplicates.

```ts
// Fix: skip toolExecutionRounds when completedRounds is present
const allOutputArtifacts = useMemo(() => {
  const result: ArtifactType[] = [];
  const rounds = response.completedRounds ?? [];
  if (rounds.length > 0) {
    for (const round of rounds) {
      if (round.toolExecution) {
        for (const execution of round.toolExecution.executions) {
          for (const a of execution.outputArtifacts) {
            if (a.type !== "display_selection") result.push(a);
          }
        }
      }
    }
  } else {
    // Single-round path: fall back to standalone toolExecutionRounds
    for (const round of toolExecutionRounds) {
      for (const execution of round.executions) {
        for (const a of execution.outputArtifacts) {
          if (a.type !== "display_selection") result.push(a);
        }
      }
    }
  }
  return result;
}, [response.completedRounds, toolExecutionRounds]);
```

How can I resolve this? If you propose a fix, please make it concise.

---

This is a comment left during a code review.
Path: ui/src/stores/chatUIStore.ts
Line: 353-358

Comment:
**Compact mode defaults `true` for all new users**

`localStorage.getItem("hadrian:compactMode") !== "false"` returns `true` whenever the key is absent (first-ever visit) or when localStorage throws. That means every new user starts with compact mode **on**, which hides reasoning sections and tool execution details by default.

Both story decorators explicitly call `useChatUIStore.setState({ compactMode: false })` to restore full detail, suggesting the canonical "show everything" view is the intended default for review/QA. If the intent is to ship compact as the default, this is fine — but it's worth double-checking whether users who upgrade from a previous release (who have never set the key) are also meant to be flipped to compact on their first load.

```suggestion
function loadCompactMode(): boolean {
  try {
    const stored = localStorage.getItem("hadrian:compactMode");
    if (stored === null) return false; // default: full view for new users
    return stored !== "false";
  } catch {
    return false;
  }
}
```

How can I resolve this? If you propose a fix, please make it concise.

---

This is a comment left during a code review.
Path: ui/src/components/MultiModelResponse/MultiModelResponse.tsx
Line: 959-963

Comment:
**Reasoning detection uses strict string equality — can misfire with identical content across rounds**

`!rounds!.some(r => r.reasoning === response.reasoningContent)` treats the current reasoning as "in-flight" only when no completed round has exactly the same string. If two consecutive rounds happen to produce identical reasoning text (uncommon but possible with short or repetitive models), the second round's reasoning would be hidden — `currentReasoning` evaluates to `null` and the in-flight `ContentRound` is suppressed until content arrives.

A more robust approach is to compare object identity or use an index/generation counter rather than the string value, for example:

```ts
const lastRound = rounds[rounds.length - 1];
const currentReasoning =
  hasReasoning && lastRound?.reasoning !== response.reasoningContent
    ? response.reasoningContent
    : null;
```

This correctly handles the common case (last committed round's reasoning will differ from the live streaming reasoning) without being fooled by identical text.

How can I resolve this? If you propose a fix, please make it concise.

---

This is a comment left during a code review.
Path: ui/src/components/ChatMessageList/ChatMessageList.tsx
Line: 113-115

Comment:
**Mode indicator `modeMetadata` read from potentially stale `group.assistantResponses`**

After this PR, the committed responses shown in the virtualizer are `committedResponses` (filtered to exclude actively-streaming instances), but the mode-badge guard on line 114 still reads `group.assistantResponses[0].modeMetadata`:

```tsx
{group.assistantResponses[0].modeMetadata?.mode === "routed" && (
```

If the first response in `assistantResponses` is currently being regenerated (and is thus excluded from `committedResponses`), the badge guard reads a potentially-absent entry while the rendered `committedResponses` array starts at a different element. This won't crash since `assistantResponses` is still the full original array, but the mode indicator could appear even when `committedResponses` is empty (no committed responses to display), resulting in an orphaned routing badge.

Consider using `committedResponses[0]?.modeMetadata` instead.

How can I resolve this? If you propose a fix, please make it concise.